Software applications are generally developed in a source language, such as C language. They often include a set of basic operations or independent or partially dependent tools. Typically, a developer or a team of developers writes files in source language and then compiles these files, according to a particular target corresponding to an execution environment, with the necessary files, notably header files and files containing compilation instructions.
Compilation produces a set of executable files representing a basic application or a tool of the targeted application. After compilation, the basic application or the tool may be installed, tested and then used. If an error is detected or if certain aspects must be improved, the source code files (or some of these files) are modified. They must then be recompiled and reinstalled.
In the field of software applications known as open or open-source applications, software applications are often delivered in the form of packages.
In Red Hat Linux (Red Hat and Linux are trademarks), there is an application management tool called RPM (Red Hat Package Manager) that permits, notably, installing and updating applications using simple commands. The packages used to deliver software applications in Red Hat Linux are often inaccurately called RPMs.
An RPM includes a set of files constituting an application. For one application, there are generally several RPMs corresponding to different versions of the latter.
Each RPM is produced from a source RPM, noted as src.rpm, containing a set of files of source code, permitting the application to be generated for different execution environments. The source RPM includes not only the source files, such as code files (*.c) and header or definition files (*.h) permitting compilation of the corresponding application, but also a set of files, called spec, used for compilation, some of which files define the order of compilation of the source code files as well as of the files permitting installation of the application.
In addition, it is observed that, in the context of certain installations, typically in a complex installation, certain software components may not be open (i.e., open source) and that as a result, the corresponding files containing the source code, called proprietary source code, are not in principle accessible to clients. However, in certain circumstances, for example, according to specific contractual clauses, a client may request the right to access the proprietary source code, in order to examine it, for example, or to be able to recompile the application.
In addition, the presence of proprietary source code on a site may be of particular interest. By way of illustration, in the event of significant problems, a maintenance team from the company that provided the software application may need components of proprietary source code in order to recompile the application locally after correction of the problem.
Thus, certain clients must have access to the proprietary source code, and this access must be blocked to other users.
In addition, it is observed that, for security reasons, maintenance teams may be prohibited from traveling with a data recording medium containing files of any kind. In other words, the files containing the proprietary source code should be obtained independently from the maintenance teams using them.
As recalled above, the RPM sources include, in particular, source code files and header or definition files. Thus, a user in possession of an RPM source file may, in a very simple manner, open it in order to explore its content and/or compile it. It is observed here that certain RPM sources may be signed using a cryptographic key permitting verification of their integrity. However, these signature mechanisms do not make it possible to selectively limit access to each file or compilation of the files.